1. Field of the Invention
The present invention generally relates to data processing. More particularly, the invention relates to debugging.
2. Description of the Related Art
A programmer develops a software program by producing and entering source code into files using a text editor program. The computer then creates an executable program by translating the source code listing into machine code. The machine code is the rudimentary language understood by a computer. Illustratively, the foregoing software development process is accomplished by running a series of programs. These programs typically include a compiler for translating the source code into machine code and a linker to link the machine code together to form a program.
When developing computer software, it is necessary to perform a function termed “debugging”. Debugging involves testing and evaluating the software to find and correct any errors and improper logic operation. An effective debugger program is necessary for rapid and efficient development of software.
A conventional debugging system comprises a combination of computer hardware and debugger software that executes a user's program in a controlled manner. Debugging aids a user in identifying and correcting mistakes in an authored program by allowing the program to be executed in small segments. This approach is enabled primarily by two operations: step functions and breakpoints.
A “step” function permits a computer programmer to process instructions (also known as “statements”) in a computer program one-by-one, and see the results upon completion of each instruction. While the step operation provides a programmer with a large amount of information about a program during its execution, stepping through hundreds or thousands of program instructions can be extremely tedious and time consuming, and may require a programmer to step through many program instructions that are known to be error-free before a set of instructions to be analyzed are executed.
To address this difficulty, conventional debuggers utilize a breakpoint operation, which permits a computer programmer to identify, with a “breakpoint”, a precise instruction for which it is desired to halt execution of a computer program during execution. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached, and then stops execution and displays the results of the computer program to the programmer for analysis.
Some conventional debuggers support unconditional breakpoints where the execution of the program is always halted upon reaching the breakpoint. Other debuggers support conditional breakpoints that halt the execution of a program only when a predetermined value is obtained when the breakpoint is encountered.
By definition, conditional breakpoints only halt the execution of a program when the conditional breakpoint's respective condition is satisfied. If the condition is not satisfied when the breakpoint is encountered, execution continues. Execution may continue during the entire run of the code. This result is typically undesirable to programmers because the programmer expects the breakpoint to fire at some point. As result, when a conditional breakpoint fails to fire, the programmer is left in the position of having to set up and re-run the program, which can be time-consuming and frustrating.
While conditional breakpoints present particular difficulties with respect to effective and efficient debugging, such difficulties also arise with non-conditional breakpoints. Source code is replete with instances of conditions giving rise to nonpredictable and varying execution paths. As a result, non-conditional breakpoints will often not be encountered during execution of the program, even though the programmer set these breakpoints with the expectation that they would be encountered.
In an effort to exert a greater degree of control over the debugging environment, programmers must spend additional time and effort to take precautionary steps. For example, when setting conditional breakpoints in a loop programmers often scan the program source code looking for the end of the loop in order to set a non-conditional breakpoint immediately thereafter. The non conditional breakpoint acts as a “safety net” which will stop execution in the event that the conditional breakpoint does not. While effective, this approach is time-consuming and increases the cost of debugging.
Therefore, there is a need for a system and method for achieving greater control and certainty over conditional situations in a debugging environment.